1. Field of the Invention
The invention relates to certificates issued for the purpose of identification, and more specifically to the determination of a certificate's validity.
2. Description of the Prior Art
Traditionally, secure tokens are physically-secured, tamper-resistant devices intended to create digital signatures, perform decryption, or otherwise perform operations using a private key or secret symmetric key. Tokens may be incorporated in hardware on a computer or may be integrated with mobile devices such as “smart cards” and wireless devices. The cryptographic implementation and the key material is enclosed in a secure shroud such that the correct operation and usage of the key can be assured. Typically, that the key will only be used upon presentation of an appropriate PIN or passphrase. The key is generally used only for approved secure operations, and the construction of the token is such that this key will not be disclosed outside of the secure shroud, and thus it cannot be copied. Often a secure token includes a signing engine and a private key, α, for which the public key is A. The public key has been certified by a Certificate Authority (CA), which has issued the certificate CA. The token is in communication with an application that makes use of the token for the creation of digital signatures, decrypting data, and the like. The application communicates a request to the cryptographic engine in the token, along with a PIN or passphrase, and the cryptographic engine executes the request using the private key. The request may be to sign a message, to decrypt an encrypted message, or some other request which would require the use of the private key. For each request posed by an application, a CA must assess the validity of that request, and therefore thr validity has to be assessed at the originating and receiving ends.
The public key infrastructure (PKI) has proven to be a secure mechanism for distributing keys and binding attributes to those keys in a trusted manner. It is intended to bind an identity to a public key such that the holder of the corresponding private key is known to be of a particular identity. In order to accomplish this task, certificates are issued which is a document that binds an identity to a public key. This binding is enforced, generally by a digital signature of a Certificate Authority. A CA is a trusted entity, trusted to provide certificates that bear signatures to individuals and entities that are able to verify their identity. A group of members that place trust in a common CA forms a public key infrastructure. When a pair of members in a PKI wish to communicate, they must verify the authenticity of each other's certificates. The difficulty however, is introduced when trying to determine if a certificate is valid on an ongoing basis and, in turn, when to reject a revoked certificate. Proposed methods to overcome this difficulty fall into several categories; namely short-lived certificates, on-line status, and revocation lists.
Short-lived certificates issued are valid for only a short period of time e.g./24 hours. These certificates are reissued regularly such that there is always a current and valid certificate. Relying parties do not need to verify the certificate's ongoing validity. If the security of a private key is compromised and reported to the certifying authority, the window of vulnerability ends when the current certificate expires and the certificate is not reissued. However, short-lived certificates require the certifying authority to reissue all of the outstanding certificates on a regular basis. This process can be computationally expensive and requires automated, online access to the certificate-signing key. This, in turn, makes the process more vulnerable to attack than a CA which can keep its key off-line and/or less automated. Further, short-lived certificates have an inherent window of vulnerability from the time the private key is compromised until the time the certificate expires. In addition, regularly reissuing and distributing the certificates is expensive, difficult to scale to larger systems, and has a single point of failure for the entire PKI.
Another method to assure certificate validity is to assess the on-line status of a certificate each time that certificate is presented. On presentation of a certificate, the relying party requests the current validity of the certificate from the certifying authority. For efficiency, an implementation may include some caching such that the status of a certificate is only retrieved from the certifying authority if the last request for its status happened long enough ago to be considered “stale.” Checking the status of a certificate online requires each relying party to contact the CA or its designated representative each time a transaction is processed. Even with the availability of at least some caching of certificate validity, the number of queries is approximately one per transaction per relying party. Further, few systems involve repeated transactions with the same party. More often it is the case that each transaction is the first time a relying party has interacted with the certified party for a period of time, even in the case where either party is involved in transactions on an ongoing basis. Furthermore, the online status requires that all relying parties have the ability to contact the CA whenever they wish to validate a certificate.
A third method to ensure the validity of certificates is through the review of a revocation list. A revocation list details certificates that have been rendered invalid, e.g./they have been revoked, and is kept by the certifying authority. The list is provided to relying parties and is updated on a regular basis and/or when new certificates are revoked. A relying party reviews the revocation list to ensure that a certificate does not appear on the list before accepting a certificate as valid. The list may take the form of a simple list of certificates or may be some other method of communicating the set of revoked certificates. Revocation lists, in some situations, may become sizable where there are many revoked certificates. Further, the lists must be reissued on a regular basis and distributed to the relying parties. In addition, revocation lists only describe the validity of a certificate at the time they are issued. When a certificate is revoked, the revocation information will not be available to the relying party until the regularly scheduled update of the CRL. If the CRL is updated before its regularly scheduled time, the relying party must contact the CA for confirmation that its local CRL is up to date. This devolves into having the same performance characteristics as checking the certificate's status online.
Most certificate validity assertions from certificate authorities, such as online certificate status messages or certificate revocation lists, bear signatures from the CA or some entity authorized by the CA to issue certificate status. This signature is necessary to indicate the accuracy of the information. Even a statement such as “The current CRL has not changed; there is no subsequent update” must be signed. Furthermore, to prevent replay attacks, most status messages must be signed for by each requestor. Protocols are designed such that the requestor is certain that the message was signed specifically for them, and is not a stale message being replayed by an attacker. This can create a very high computational and communication burden on the CA and its authorized representatives. The result is a system that is not particularly scalable.
With existing methods, as described above, the validity of a certificate is determined by the relying party at the time of reliance on a certificate and is thus subject to any error windows resulting from a delay in updating validity information. This can lead to both positive and negative errors. In the case where a relying party is sending a message, the relying party determines that a certificate is valid, encrypts the message, and sends it. At some later point, the private key of the recipient is compromised and the recipient's certificate revoked. However, all existing encrypted messages may still be decrypted, even though the certificate is no longer valid. Further, in the case where a user generates a valid signature using their private key, if that private key is later compromised and the certificate is revoked, the signature can no longer be validated, even though it was generated correctly and securely. The problem resides in the fact that the validity of a certificate controls the use of the public key since it is consulted by relying parties who are about to use a certificate. However, the validity of a certificate also communicates the security of the private key in that a certificate is revoked when the holder of the private key can no longer be associated with the identity or privileges communicated in the certificate.
It is an object of the present invention to obviate and mitigate at least some of the aforementioned disadvantages of the prior art.